NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/6399

Internet Message Format | 1996-08-05 | 3.8 KB

Path: fourier.newcastle.edu.au!peter
From: [e-mail] (Peter Moylan)
Newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.c,comp.lang.modula3,comp.lang.modula2
Subject: Re: Hungarian notation
Followup-To: comp.lang.ada,comp.lang.c++,comp.lang.c,comp.lang.modula3,comp.lang.modula2
Date: 7 Feb 1996 22:35:27 GMT
Organization: The University of Newcastle
Message-ID: <4fb9ff$[e-mail]>
References: <[e-mail]> <[e-mail]> <4e7ifl$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <4f41vf$[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: fourier.newcastle.edu.au
X-Newsreader: TIN [version 1.2 PL2]

Richard A. O'Keefe ([e-mail]) wrote:
>Douglas Evan Cook <[e-mail]> writes:
>>Good grief :)  You just declare one type as another.  In Pascal or M2, try
>>TYPE
>>  INT16 : INTEGER;

>This is not legal Pascal syntax.  Is it legal Modula 2?

There was a minor typo here.  If you replace the ':' by '=' then
it's legal Modula-2.

>The original poster's point remains:  the
>    <type name> = <type term>;
>construction in Pascal does not create abstract data types and does not
>"unify" anything, let alone "thousands of ADTs".

Perhaps not, but there are two separate issues here.  If all
you want to do is mimic the C typedef facility, then the above
is a way to do it.  If instead you want to implement an
abstract data type, you certainly can do that in Modula-2
but it would be silly to do it simply by mimicking the
C approach - that would amount to throwing away some of the
benefits of Modula-2.  In fact you wouldn't often find a
type definition like the above in typical Modula-2 modules.
Likewise for other high-level languages like Ada, Modula-3, etc.

There seems to be a general misunderstanding in this thread
about the motivations for using the abstraction and information
hiding facilities of languages like Modula-2.  The point is
not primarily to hide things from the programmer, since
typically the programmer has the option of going and looking
at the source code anyway.  Rather, the point is to enhance
portability, code reliability, and ease of programming, by
letting the programmer concentrate on his own area of
responsibility, and being able to use facilities provided by
other modules, without having to keep checking for
unintended side-effects that are dependent on how those
other modules are implemented.

If you want an abstract data type, then you create a module
that defines that type (usually without revealing the details
of its internal representation) and defines the operations
that can be performed on the type.  If subsequently you need
to use a different internal representation (e.g. you change
data structures for efficiency reasons, or you're doing
something machine-dependent and you port the code to another
machine), then all you have to do is update the internal
implementation of the ADT and - this is the important point -
YOU DON'T BREAK ANY OF THE CLIENT CODE.

In the specific case of implementation details that depend
on the underlying representation (e.g. reading data produced
by a machine with a different architecture), the representation
details are all collected in one place and program porting
becomes very easy.

There seems to be a very common tendency among C/C++
programmers to use typedefs to introduce low-level types
like int16.  Modula-2 programmers use type definitions for
exactly the opposite reason: to introduce high-level types
in such a way that the user doesn't have to worry about
what the underlying representation looks like.

--
Peter Moylan                       [e-mail]
                           ftp://ee.newcastle.edu.au/pub/www/Moylan.html